本系列討論企業導入 AI／Agent 時，工具明明做完了，工作卻沒有因此變好的決策現場。
Day 02：使用者最清楚工作卡在哪裡，但不需要先替解法命名。

工作坊開始前，顧問在白板上畫了三個欄位。

Agent 名稱｜目標使用者｜預期效益

每個部門桌上都放著一疊便利貼。

主管說，今年每個部門至少要提出一個 AI Use Case。技術細節可以之後再談，今天只要從自己的工作出發，想一個最值得做的 Agent。

行銷部先寫下「多語內容生成 Agent」。

人資部提出「員工服務智慧助理」。

財務部寫的是「營運洞察 Agent」。

資訊部也很快補上一張：「智慧維運協作 Agent」。

不到半小時，白板上已經貼滿各種名稱。

坐在最後一排的客服營運窗口還沒動筆。

顧問走過去問她：「你們部門有沒有重複、很花時間的工作？」

她想了一下。

「每天早上，我們要先看前一天晚上進來的 Ticket。」

「那可以做 Ticket Agent。」

「不只是分類。有些是同一個問題重複回報；有些沒有產品版本和環境資訊；有些本來就該轉給別的團隊。轉錯後通常半天才會退回來。」

顧問順手拿起一張便利貼。

「智慧 Ticket 分流 Agent？」

她看著那張便利貼。

「我不知道這是不是 Agent。我只是想讓大家不要每天早上花四十分鐘，把一堆不能處理的 Ticket 重新確認一次。」

工作坊結束時，白板上共有二十四個 Agent 名稱。

她的位置前面仍然是空的。

問題說得很清楚，提案卻還不能開始

兩週後，AI 推動小組開始審查各部門提交的 Use Case。

「多語內容生成 Agent」的效益寫著「提升內容產製效率」，但尚未限定內容類型、使用者，或產出後由誰確認。

「員工服務智慧助理」預計回答公司制度、福利規定、教育訓練與各部門公告。資料來源很多，不過哪些文件仍然有效、規定衝突時由誰處理，都還沒有答案。

「營運洞察 Agent」要整合多個資料來源，主動發現異常並提出建議。至於異常是什麼、建議交給誰、收到建議後要做什麼，則被放在「後續釐清」。

這些都不是爛提案。

它們只是先有了產品名稱，工作內容還在後面。

輪到客服營運部時，投影幕上沒有 Agent 名稱，只有一段工作紀錄。

觸發時間：每天上午九點前

輸入：
- 前一晚新增的客服 Ticket
- 產品版本、回報環境與錯誤訊息
- 歷史相似案例

目前工作：
- 合併重複問題
- 找出缺少資訊的 Ticket
- 判斷負責團隊
- 標記需要優先處理的案件

目前成本：
- 每天約四十分鐘
- 分錯團隊時平均延遲半天

審查人員問：「你們希望系統做到哪一步？」

窗口回答得很具體：先找出重複問題與缺少資料的 Ticket；轉給哪個團隊可以提出建議，但不要直接送出。每天早上還是會有人確認，退回的案件也能用來看分流判斷是否失準。

目標也不複雜：整理時間從四十分鐘降到十五分鐘，退件比例下降。

到這裡，技術團隊才有足夠資訊判斷下一步。

它可能是分類模型，也可能是規則加上相似案例搜尋；若資料欄位本身不完整，先調整表單或提交流程或許更有效。Agent 是其中一種可能，不是需求本身。

使用者不需要先設計產品

「請每個部門提出自己的 Agent Use Case」看起來很合理。

它尊重現場，也能很快收集大量題目。但這句話其實把三件不同的工作綁在一起：

1. 描述現在遇到的問題。
2. 把工作拆成能被處理的步驟。
3. 選擇 AI 解法與產品型態。

第一件事，現場使用者通常最清楚。

他知道哪些 Ticket 每天都會卡住、什麼資訊少一次就得多追一輪、哪個團隊最常收到不該屬於自己的案件。

第二件事已經是流程分析。

第三件事則接近產品與技術設計。它可能是固定規則、一支 Script、一個分類模型、一套 Workflow，或具備 Tool Calling 的 Agent。

這不該由一個每天處理 Ticket 的人獨自決定。

當組織直接問「你想做什麼 Agent」，使用者只能從自己聽過的能力開始拼答案：整理資料、自動分析、建立知識助理、做智慧決策。

那些詞可以作為訪談起點，卻還不足以排進開發計畫。

把第一欄換成工作，不是把表格換個名字

需求收集表不一定要很長，但第一輪至少應該先拿到以下內容：

這件工作在什麼情況下發生？
現在由誰處理？收到哪些資料？
實際做了哪些步驟？
哪一步最耗時、最容易出錯，或最依賴經驗？
哪些判斷仍必須由人做？
如果判斷錯了，能不能被發現與修正？
最後想改善的結果是什麼？

這些不是為了讓使用者寫出更漂亮的需求文件。

它們要回答的是：問題究竟在資料、流程、責任邊界，還是在某個適合交給 AI 協助的判斷環節。

在這之前先討論 Agent 名稱，通常只會讓團隊提早鎖定解法，之後再花時間替它找用途。

那張表後來被退了回去

審查會結束後，AI 推動小組把原本的提案表退回各部門。

新版表格刪掉了第一欄的「Agent 名稱」。

第二輪訪談後，原本二十四個提案中，有十七個被合併、改寫或取消。

有些部門最後要的是更好的搜尋；有些是資料格式不固定；也有幾個題目，談到工作步驟後就不再需要做新工具。

客服營運部的案子進入小規模測試。它先處理重複案件與缺件提示，分流仍由人確認。

正式立項時，那個案子才有了名字。

白板上的二十四個名稱沒有直接變成二十四個專案。真正留下來的，是一份能讓人開始判斷的工作紀錄。

下一篇：Day 03｜他們先替問題取了一個名字